OOP (Object-Oriented Programming)

  • Focuses on objects, which are instances of classes, and the interactions between those objects. State and behavior are encapsulated inside objects.

  • It is a paradigm but can be used as a basis for architectures.

Thoughts

  • (2025-01-24) A public method should not return information about an internal node.

    • Avoid this: 

      func get_inventario_runtime() -> Array[Dictionary]:
    return _grid_slots.get_inventario_runtime()

Concepts

  • Encapsulation :

    • Association with SOLID :

      • Single-responsibility principle.

      • Dependency inversion principle.

    • "Encapsulation prevents external code from being concerned with the internal workings of an object."

    • "The best functions are those with no parameters".

    • Encapsulation {2:02 -> 3:29} .

  • Inheritance :

    • Association with SOLID :

      • Liskov substitution principle.

      • Open-closed principle.

    • When to use Inheritance (Hierarchical Reuse and Subtype Polymorphism) .

      • You can use Inheritance, but only when you want both  Hierarchical Reuse of Code and Subtype Polymorphism.

      • {Only Hierarchical Reuse of Code}

        • If you don't plan to override any parent class behavior, using a Parent Class makes no sense; use Composition instead.

        • "Has a" vs "Is a" -> Composition over Inheritance.

      • {Only Subtype Polymorphism}

        • If you only plan to override a method of the Parent Class, it makes no sense for it to be a Parent Class; use an Interface.

      • {Avoid Inheritance}

        • "Should one always  use Inheritance when wanting both Hierarchical Reuse of Code and Subtype Polymorphism? No!"

        • The presenter prefers using Interfaces for Subtype Polymorphism and Composition for Code Reuse.

      • Great video.

    • Virtuals: Using 'super()' to reproduce the original function content {8:00} .

      • "Functions in extending classes replace functions with the same name in their super classes. If you still want to call them, you can use super() ".

    • Difference between Class Inheritance and Interface Implementation:

      • Both are forms of "inheritance", but the first is Concrete while the second is Abstract.

      • The syntax is exactly the same in C#, but the word Implementation is used for Interfaces. It's a convention to differentiate Concrete behavior from Abstract behavior.

  • Polymorphism :

    • Association with SOLID :

      • Liskov substitution principle.

      • Dependency inversion principle.

    • "Many forms".

    • Subtype Polymorphism:

      • Allows removing conditional logic (if/else and match) via classes that represent subtypes of the class they "inherit".

      • Subtype Polymorphism can be achieved via Class Inheritance or Interface Implementation. Both are forms of "inheritance", but the first is Concrete while the second is Abstract.

      • Subtype Polymorphism {5:27 -> 6:22} .

      • When to use and not use Subtype Polymorphism .

        • The video's proposal differentiates 'data variations' vs 'behavior variations', so for the first use Classes, for the second use Interfaces.

        • The first example is interesting.

        • In the 3rd example, 'IMove' is better translated to 'IAbility'.

  • Abstraction :

    • Association with SOLID :

      • Interface segregation principle.

      • Dependency inversion principle.

    • Hides internal implementation details, exposing only essential functionality. This facilitates creating modular and maintainable systems.

Good Practices

  • Christopher Okhravi .

    • Good channel.

  • SOLID :

    • Single-responsibility principle :

      • "There should never be more than one reason for a class to change. In other words, every class should have only one responsibility."

    • Open-closed principle :

      • "Software entities ... should be open for extension, but closed for modification."

    • Liskov substitution principle :

      • "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it."

      • a.k.a. "whatever the parent can do, the descendants should at least be able to do that".

      • The Square-Rectangle Problem .

        • It's an interesting problem about whether Square or Rectangle should be Super-type or Sub-type; the answer is: they should not be related.

        • Nice video.

      • Liskov Substitution Principle .

        • I didn't like the video. It's super technical without adding much. 'Type Rules' and 'Behavior Rules' are very similar, everything is based on Contravariance and Covariance.

    • Interface segregation principle :

      • "Clients should not be forced to depend upon interfaces that they do not use."

    • Dependency inversion principle :

Interface vs Abstract Class

  • About abstraction:

    • The fundamental difference between an abstract class and an interface is that an abstract class can contain both concrete (implemented) and abstract (unimplemented) methods, while an interface can only contain abstract method signatures. This matters because an abstract class can provide default implementations that subclasses inherit. An interface only defines method signatures that implementing classes must provide, without any implementation.

  • About constructors:

    • An abstract class can have constructors, fields, and instance methods.

    • Interfaces are contracts that specify the methods a class must implement, but they do not contain implementations or internal state like fields or constructors.